In recent years, among computer networks (referred to as “network” hereinafter), software defined network (SDN), especially data center network, has been just started to be utilized. In an SDN, network processing is divided into the control plane (C-plane) and the data plane (D-plane), and the D-plane is controlled by the C-plane having a logically centralized control architecture.
In software defined networking, there is OpenFlow, a system to control the D-plane. In OpenFlow, an OpenFlow controller (OFC) and an OpenFlow switch (OFS) are defined as the C-plane and the D-plane, respectively, and so are control messages between the OFC and the OFS, the functions of the OFS, and the API. The specifications of OpenFlow are described in detail in Non-Patent Literatures 1, 2, and 3.
FIG. 21 is a drawing showing a data center network architecture X1 configured using OpenFlow. Servers X10a and X10b are connected to edge OpenFlow switches X12a and X12b. At least one core OpenFlow switch X14 is provided in order to connect the edge OpenFlow switches X12a and X12b to each other. An OpenFlow controller X16 that controls these switches is connected using network management links X20. The network management link X20 is called “secure channel,” and it is recommended that it be encrypted using SSL (Secure Socket Layer). Note that, however, whether or not the secure channel is encrypted is up to the discretion of the network operator. Further, the servers X10a and X10b are lumped together and referred to as the server 10 hereinafter when there is no need to distinguish between them. Similarly, the edge OpenFlow switches X12a and X12b are referred to as the OpenFlow switch X12.
FIG. 22 is a drawing showing a general configuration of the OpenFlow controller X16. In general, the OpenFlow controller X16 is realized as a software application running on a server. More specifically, it is realized as an application program running on an OS (Operating System) such as Linux (registered trademark).
With reference to FIG. 22, the OpenFlow controller X16 comprises a packet input/output module X164, a decryption module X166, an encryption module X168, and an OpenFlow message control module X170.
The packet input/output module X164 is generally constituted by a protocol stack constituted by TCP/IP (Transmission Control Protocol/Internet Protocol), etc., and an application interface such as a socket API (Application Programming Interface).
The decryption module X166 and the encryption module X168 are modules that decrypt and encrypt, respectively, the data portion of a packet flowing through the network management link X20. In OpenFlow, when encrypted communication is performed using the network management link X20, SSL (Secure Socket Layer) is used to encrypt the payload of a TCP (Transmission Control Protocol) packet. Therefore, in the OSI (Open Systems Interconnection) reference model, these processes are included in the session layer, a layer above the transport layer. Refer to Non-Patent Literature 5 for the details of SSL.
The decryption module X166 decrypts an OpenFlow message received from the packet input/output module X164 and hands the decrypted message to the OpenFlow message control module X170.
The encryption module X168 encrypts an OpenFlow message received from the OpenFlow message control module X170 and hands the encrypted message to the packet input/output module X164.
The OpenFlow message control module X170 is a module that controls the transmission/reception of messages to/from the OpenFlow switch X12. Various types of control messages are defined in OpenFlow, and the OpenFlow message control module X170 constructs a message to be transmitted and analyzes a received message. The control messages will be described more later.
FIG. 23 is a drawing showing a general configuration of the OpenFlow switch X12. The OpenFlow switch X12 comprises a packet input module X1200, a packet forwarding processing module X1210, a flow table X1220, an OpenFlow message processing module X1230, a secure channel control module X1240, and a packet output module X1250.
The packet input module X1200 is a module that receives a packet from the outside of the OpenFlow switch X12, and the packet output module X1250 is a module that outputs a packet externally from the OpenFlow switch 12. In reality, these modules correspond to ports of a hardware switch.
The packet forwarding processing module X1210 refers to the flow table X1220 using packet header information of a packet received from the packet input module X1200 to determine the processing (action) on the packet. Processing examples performed by the packet forwarding processing module X1210 include rewriting a packet header, outputting a packet to a designated port, and forwarding a packet to the OpenFlow controller X16. Further, sending an inquiry to the OpenFlow controller X16 is an example of processing performed by the packet forwarding processing module X1210 when no corresponding processing is found in the flow table X1220. When sending an inquiry to the OpenFlow controller X16, the packet forwarding processing module X1210 sends a inquiry request to the OpenFlow message processing module X1230 along with packet information.
The OpenFlow message processing module X1230 is a module that processes a message used in the OpenFlow protocol and performs processing such as constructing an OpenFlow message according to a request from the packet forwarding processing module X1210 or interpreting an OpenFlow message received from the OpenFlow controller X16. According to Non-Patent Literature 2, default OpenFlow messages can be broadly divided into asynchronous messages, controller-to-switch messages, and symmetric messages. Refer to Non-Patent Literatures 2 and 3 for the details of each message.
The secure channel control module X1240 is a module that controls a packet flowing through the network management link X20 between the OpenFlow controller X16 and the OpenFlow switch X12. For instance, the secure channel control module X1240 performs processing such as forwarding an OpenFlow message to the OpenFlow controller X16 and forwarding an OpenFlow message received from the OpenFlow controller X16 to the OpenFlow message processing module X1230 according to a request from the OpenFlow message processing module X1230. Further, when encrypting a packet flowing through the switch management link X20, the secure channel control module X1240 also executes encryption and decryption processing.
Until recently, OFSs has been mainly realized by hardware switch products, however, due to the expansion of the server virtualization technology, a virtual switch (vSwitch) used for forwarding packets between virtual machines (VM) within a server or between a virtual machine and an external network has started to support OpenFlow. An example of this is the Open vSwitch described in Non-Patent Literature 4. Therefore, the range of networks controllable by SDN has started to include a network of VMs within a server.
FIG. 24 is a drawing showing a server virtualization environment and a virtual switch constructed in the server X10. With reference to FIG. 24, a virtual switch X120 is implemented inside a virtual machine monitor (VMM) X100. Virtual machines X110 communicate with each other via the virtual switch X120. The packet input module X1200 and the packet output module X1250 shown in FIG. 23 correspond to a link between a VM and the virtual switch X120 and to an Ethernet (registered trademark) port provided in the server X10.
FIG. 25 is a drawing showing a data center network architecture X2 that includes the virtual switch X120 within the server X10. Note that, in FIG. 25, the virtual machine X110 and the virtual switch X120 are referred to as the virtual machines X110a and X110b, and the virtual switch X120a and X120b, respectively, corresponding to the edge OpenFlow switch X12. With reference to FIG. 25, the virtual switch X120 and the OpenFlow controller X16 are connected by the network management link X20 as well, and the OpenFlow controller is able to control the virtual switch X120.
In OpenFlow, the OpenFlow switch X12 processes a packet according to the flow table X1220 provided therein. In the flow table X1220, entries associating a matching rule defined in the header information included in a packet header with an output destination port of the packet and processing (Instruction) on the packet header are registered as flow entries. The OpenFlow switch X12 sends an inquiry to the OpenFlow controller X16 via the network management link X20 about a packet not registered in the flow table and unprocessable by the OpenFlow switch X12. This inquiry is called packet_in. In addition to these inquiries, a packet_in occurs when the OpenFlow controller X16 is designated as the output destination of a packet.
The OpenFlow switch X12 forwards a message in the form of a packet_in message to the OpenFlow controller X16 according to the OpenFlow specification. FIG. 26 shows an outline of a packet_in message X200. The packet_in message X200 includes an OpenFlow header X210, which is a header dedicated to OpenFlow, a packet_in message header X220, and packet data X230, which is the packet that started the packet_in message. In OpenFlow, a case where the entire packet (Ethernet frame) is used as the packet data X230 and a case where a portion of the packet is used are defined. In the latter, the OpenFlow switch X12 internally buffers the packet and writes a buffer ID indicating where the packet is stored to a buffer ID field provided in the packet_in message header X220. Further, when the OpenFlow switch X12 does not have any packet buffered, the buffer ID field has a value indicating an invalid buffer written therein.
Other pieces of information included in the packet_in message header X220 include fields indicating the length of the packet data X230 and the reason for starting the packet_in message.
Upon receiving the packet_in message X200, the OpenFlow controller X16 determines what processing will be performed on the packet that has started the packet_in message. If necessary, the OpenFlow controller X16 instructs the OpenFlow switch X12 to add a flow entry using a flow_mod message or forward the packet using a packet_out message. Adding a flow entry using a flow_mod message will enable the OpenFlow switch X12 to perform data plane processing on a packet having the same information without sending an inquiry to the OpenFlow controller X16 thereafter.
FIG. 27 shows an outline of a packet_out message X250. Like the packet_in message X200, the packet_out message X250 includes the OpenFlow header X210, which is a header dedicated to OpenFlow, a packet_out message header X225, and the packet data X230, which is the data of the packet that the OpenFlow controller X16 wants the OpenFlow switch X12 to forward to its destination.
The packet_out message header X225 includes a field indicating a list of processing (actions) performed by the OpenFlow switch X12, in addition to a field specifying a buffer ID.
By specifying the buffer ID included in the corresponding packet_in message X200 in the packet_out message X250, the OpenFlow controller X16 is able to instruct packet data buffered in the OpenFlow switch X12 to be forwarded without having the packet data forwarded to the OpenFlow switch X12. Upon receiving the packet_out message X250, the OpenFlow switch X12 reads out the packet from the buffer and processes the packet according to the packet_out message X250. Further, when the packet data X230 of the packet_out message X250 is valid data, the buffer ID field of the packet_out message header X225 has a value indicating an invalid buffer written therein.
The operation related to packet_in and packet_out is the same for vSwitch that supports OpenFlow. At the same time, vSwitch differs from the conventional OpenFlow switch X12 in that it is a software program within a server and that it is generally utilized while being incorporated in server virtualization software and an OS. In other words, the format of processed data is not that of packets or frames flowing through a network, but it is the data format utilized within a server such as the socket buffer structure. As a result, in addition to data incorporated in a packet as header information, data utilized in processing within a server can be held. Such data that accompanies a packet is referred to as ancillary data.
Examples of ancillary data include data written to a control buffer (CB) region included in the Linux socket buffer structure. Other examples of ancillary data are tenant information in a multi-tenant data center and tunnel information for network tunneling.
Patent Literature 1 discloses a configuration in which proactive-type packet forwarding is performed by having an edge OpenFlow switch of an OpenFlow network convert a packet header, having a core OpenFlow switch forward a packet using the converted packet header as a matching condition, and then having an edge OpenFlow switch connected to a receiving station restore the packet header.    Patent Literature 1:    International Publication Number WO2012/096131 (A1)    Non-Patent Literature 1:    “Open Networking Foundation,” [online], [searched on Aug. 12, 2013], the Internet <http://www.opennetworking.org/>    Non-Patent Literature 2:    “OpenFlow Switch Specification” Version 1.3.1 (Wire Protocol 0x04), [online], [search on Aug. 12, 2013], the Internet <https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.1.pdf>    Non-Patent Literature 3:    “OpenFlow Switch Specification” Version 1.0.0 (Wire Protocol 0x01), [online], [search on Aug. 12, 2013], the Internet <https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf>    Non-Patent Literature 4:    “Open vSwitch An Open Virtual Switch,” [online], [search on Aug. 12, 2013], the Internet <http://openvswitch.org/>    Non-Patent Literature 5:    “The Transport Layer Security (TLS) Protocol Version 1.2,” [online], [search on Aug. 12, 2013], the Internet <http://tools.ietf.org/html/rfc5246>